Non-volatile storage devices, such as flash memory devices, communicate with their host device (e.g., a digital camera) by using a communication protocol, which allows the host device and the non-volatile storage device to exchange data and various types of messages. For example, if the host device wants to write (or read) data to (or from) the storage device, the host device communicates to the storage device a corresponding “Write” (or “Read”) instruction.
Host devices usually include an interrupt control module (referred to herein as “interrupt controller” (IC)), such as a Programmable Interrupt Controller (PIC), for handling interrupts as they occur. Upon receiving an interrupt signal, the host device's interrupt controller checks its priority and forwards it to an intended hardware unit or application within the host for handling. Traditionally, storage devices have been designed to wait until they are addressed by their host, for which reason they are commonly referred to as “slaves”, as opposed to their hosts which are commonly referred to as “masters”. An aspect of the traditional design of storage devices is that storage devices do not have an access to their host's interrupt controller, which leaves much, if not all, of the communication initiative to the hosts. Sometimes, though, it is useful to render a service to a slave storage device before its “waiting period” (i.e., the time elapsing from the last visit till the next time the host visits the storage device) runs out. In general, to get a service from a master host the slave storage device sends a service request to the master host. However, because, as explained above, slave devices do not have an access to their host's interrupt controller, the slave device has to wait until it is addressed by its host, during which waiting period the service request is said to be “pending”. This conduct poses a problem because the host also handles other tasks, for which reason it may take a while before the master host addresses the slave device. Therefore, the host is not aware in real-time of the storage device requiring a service, which slows down the interaction between the slave storage device and the host.
Master hosts usually address their slave storage devices by using a polling mechanism; i.e., the master host addresses (“visits”) one slave device at a time to check whether the currently addressed storage device has a message or a pending service request waiting for the master host, or the slave device needs to exchange information with the master host.
Using a polling mechanism has several deficiencies. In order to respond to messages originating from slave storage devices, the polling mechanism has to be active continuously. However, an active polling mechanism consumes power and handheld devices, such as mobile phones, are highly power-constrained. One implication of this is that processes executed in battery-operated systems have stringent power constraints. In addition, if the polling mechanism is active continually other processes, applications, and circuits, of the host cannot enter a “sleep” mode, which exacerbate the power consumption problem. Therefore, in some systems, the polling application is switched off momentarily, at times, to conserve battery power. However, switching off the polling application “blinds” the host. It blinds the host in the sense that, as long as the polling application is inactive, the host cannot be aware in realtime of any pending service request originating from, or of a process that is executed in, the slave device. Therefore, it would be beneficial to have a mechanism that will circumvent the problem of a slave storage device not having a direct connection to the interrupt controller of its host, and that will enable the host to “sense” in real-time when the slave storage device needs a service, regardless of the existence or absence of a polling mechanism.